I keep getting a particular type of crash report for my macOS app (FAF) that I cannot figure out. Here's the top of the stack trace which all reports have in common: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib … objc_msgSend + 29 1 com.apple.AppKit … -[NSPathControl _performDragOfCell:fromMouseDown:] + 130 2 com.apple.AppKit … -[NSPathControl mouseDown:] + 300 3 com.apple.AppKit … -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4961 What I figured out so far: Is triggered by a click or double click on a segment of the NSPathControl. For some users it has been happening more than once, but not often enough for me to figure out what's behind it. I have not been able reproduce it even once. Leads to a "Segmentation fault: 11" Happens in macOS versions from at least 10.8 until the most current (11.4). In both Intel and ARM code. The call stack does not show any of my own code involved. The app's other threads are all idle. Some reports do not list any non-Apple extensions or dylibs as far as I can tell. When I googled "crash NSPathControl setHighlighted", I could only find a single other mention of it, but that crash even happened in Finder, on OSX 10.8.1. The person reporting it had quite a few other system extensions loaded but eventually figured out that it got fixed when he changed his Wacom tablet's behavior from not issuing a triple click any more. I tried to create triple clicks, along with combined drags, even using SteerMouse to have a triple click event generated by a separate mouse button, but to no avail. Has anyone else seen this type of crash? Any idea what may be behind this? I have two complete crash reports (with only some privacy related lines removed at the top) uploaded here: https://gist.github.com/tempelmann/5c519244ffc7a485afa66d546a9b9712 https://gist.github.com/tempelmann/315f8122b8079637cb5a9bf299ac380a

sample.ips.txt Xcode, MacSymbolicator and QuickLook all fail to consider the symbols from the lastExceptionBacktrace of a modern .ips crash report. I have attached a full report as an example (I had to change its extension to txt or I wouldn't be able to upload it - change it back to ips and then use Quicklook to see its contents, which will be missing the backtrace). Here's the excerpt that matters: "lastExceptionBacktrace": [ { "imageOffset": 992564, "symbol": "__exceptionPreprocess", "symbolLocation": 164, "imageIndex": 13 }, { "imageOffset": 106164, "symbol": "objc_exception_throw", "symbolLocation": 60, "imageIndex": 25 }, { "imageOffset": 274836, "symbol": "-[__NSDictionaryM setObject:forKeyedSubscript:]", "symbolLocation": 1176, "imageIndex": 13 }, This trace is missing from a symbolicated report - I only get to see the main threads. Here's the start of that report: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Find Any File [2616] Path: /Applications/Find Any File.app/Contents/MacOS/Find Any File Identifier: org.tempel.findanyfile Version: 2.4.1 (355) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2024-01-09 11:31:33.8066 -0600 OS Version: macOS 14.3 (23D5043d) Report Version: 12 Anonymous UUID: E3DD5ECE-F28C-31BA-A2EA-DE39D4284163 Time Awake Since Boot: 990 seconds System Integrity Protection: enabled Crashed Thread: 11 Dispatch queue: Folder size calc (Macintosh HD) (QOS: UNSPECIFIED) Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Find Any File [2616] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreAutoLayout 0x18cecbdd8 -[NSISEngine hasValue:forEngineVar:] + 284 1 AppKit 0x187f51894 NSViewActuallyUpdateFrameFromLayoutEngine + 128 2 AppKit 0x187f11790 -[NSView layout] + 636 Contrary to this, when I get a similar crash report from an older macOS version where it still uses the older .crash instead of .ips files, I get to see the backtrace and can symbolicate it as expected. This seems to be a major bug in the symbolicator for ips files, and it's been around for years. I'm surprised that this is still not taken care of. Am I the only one who's noticing this?

Update: Turns out it works for others, apparently, and I also found one of my Macs where it does work, too. So it must be something pertinent to my systems. Oddly, though, the same ones where it now fails used to work because I had TestFlight enabled there before. I have TestFlight set up on App Store Connect, and I have already about 50 testers subscribed. Today, I found that the Public Link does not work any more: Once TestFlight.app is installed, and one clicks the link to add my app to TestFlight, it always shows the error ""Unable to Open Link" in TestFlight.app: I've tried this on several Macs (Ventura and Sonoma), and with different Accounts, both where the app was already added or not. Is something generally broken, i.e. do others see the same issue with their TestFlight links, or is it just me? How do you suggest I get this resolved? Here's an example link I set up for this purpose - it only allows a handful of subscribers, so please do not actually subscribe but just see if you even get allowed to, or if you get the same error if you must try: https://testflight.apple.com/join/oV8NNojg And here's how it's set up:

I have an app in the App Store that doesn't need to be sandboxed (it's been in the MAS since 2010, before sandboxing became mandatory for new apps). I have run into an obscure bug that ONLY appears when the app was installed by TestFlight, but not when I run the same executable from before the upload (taken from the very same archive). I suspect it's a bug around the installed receipt or is codesign related, because that's the only things I am aware of that would be changed between my upload and the re-download via TestFlight. To debug this, I have built a small test project that I want to submit to DTS, demonstrating the bug in a clear and direct manner. But when I try to upload it, even for "internal testing" only, the upload gets rejected automatically because it's missing the App Sandbox entitlement. However, if I add the entitlement, then my app won't work, so I cannot enable it. Hence I need to get an exception from App Review so that they allow me test app being uploaded without the sandbox entitlement. I know that's possible because otherwise I'd not be able to upload my regular application, which I did just the other day. How do I get this resolved? Would a member of the App Store team please contact me? The Apple ID for the test project is: 410006334. Or, alternatively, you can also use the newer 6503298614 (I tried the other in hopes it would be allowed not to be sandboxed because I had created it long ago, but that didn't work out).

My app (Find Any File) behaves strangely on Sequoia: When the code calls the window's makeFirstResponder on the NSSearchField item in the window's toolbar, and if the toolbar is currently showing the small loupe icon, it should: Switch to showing an NSTextView in place of the loupe icon Make the text view the first responder so that the user can type in it. This used to work reliably before macOS 15, but in 15.0.1 and also the current 15.1 beta it often misses step 1 or or step 2. When it misses step 1, then the window's first responder reports back to it's set to the text field, but its frame is very narrow (width is 4 isntead of 192). And when it misses step 2, then the textview is visible but hasn't gained focus - instead, the main window is the first responder. This happening is quite random. I find no pattern. Even worse, after calling makeFirstResponder, if I check the window's first responder, it's always the expected NSTextView, even if I delay the check with dispatch_async(dispatch_get_main_queue(), ^{ …. So I cannot even reliably detect when this goes wrong in order to act on it. Has anyone else noticed this to happen in their apps?

I have several ObjC based apps in the App Store and used to validate the receipt file inside the app in my code, and then reject it with exit(173) if it's invalid, which did trigger macOS to update the receipt if possible. This isn't working any more in recent macOS versions, where the user is instead just told that the app is damaged, and they need to re-install it manually. Which sucks. So I wanted to update my code. I read about SKReceiptRefreshRequest, which is supposed to re-download and install the receipt file, if I understand it correctly. I implemented the code but now have trouble verifying that it works as intended, and does this in a user friendly way. I found in my tests that macOS now caches the receipt in ~/Library/Caches/com.apple.appstoreagent/fsCachedData and then hardlinks the file into the app. BTW: Sadly, this also requires that the app is located on the startup volume or the system will refuse to install the receipt, which wasn't a requirement in past times. Now, if the receipt is already present in the cache folder, then my code works - the receipt gets re-linked. But what if the cached receipt isn't there, yet? Such as that the user had copied the app from another Mac over to a freshly installed Mac? In the past, when the user then launched the app on the new Mac, he'd be prompted to login to the MAS and if that worked, the receipt would get installed and the app launched. Basically, the question is: What if the receipt validation fails in my app and I request a new receipt, but the user has not yet logged into MAS (e.g. new computer)? To simulate this, I logging out of the MAS and TestFlight, deleting all copies of the app and then run the app that I had copied from another Mac where it was authorized with a valid receipt for that device. If I do this with the old version that uses exit(173), I get these two messages in macOS 15.2: The second one is especially terrible because it shows the translocated path, which the average user surely get quite confused, and then maybe even search in vain for the app in there and get frustrated. But that's out of my hands. Sigh. Now, that was proving that the old method with exit(173) isn't working any more and needs to be changed in my apps. Since I'm still developing (testing) this new behavior, the app is therefore not in the MAS yet - the only way for me to test this is to use TestFlight. However, running a Testflight app copied from another Mac leads to this error: That is not helpful in simulating what would happen if this app was released in the MAS. This won't let me find out what happens if my app is run on a Mac where the receipt fails and I ask it to load it via SKReceiptRefreshRequest and if the user is NOT yet logged into the MAS account for this purchased app of his/hers. That leaves only one option: Release the app with untested code and hope for the best. Contrary to this new behavior, the old method did let me test this easily because I would just use the special App Store tester account with the MAS app, i.e. the built MAS app would, when I launched it locally, request for a login and I'd provide my tester's account. But this isn't available any more, apparently. What a mess.

I have a macOS app that contains multiple additional executables. One is a full app bundle, the others are single-file tools with an embedded plist. So far, I have used Xcode 13 to upload the app to the MAS. This had not (and still does not) report any warnings. But today, when i tried to upload (or Verify) with Xcode 16.2, I am getting this warning: I cannot make sense of this. Clearly, the placeholders are not properly filled out, but even if I remove any one of the items from the app, the verification keeps report the same warning. Only if I remove ALL of the embedded app and executables, the warning goes away. Now, the problem is that I can't see what I need to do. My Xcode signing setting are set to "Automatic", and it shows "Provisioning Profile: None required" for the main and all involved sub projects. And I never needed one (the app is not sandboxed and doesn't have to be - it's exempt), and the app was always accepted this way and runs on 10000s of Macs like this, with all executables doing their job as intended. So, what's this warning about and is that a false flag (e.g. should only be posted for sandboxed apps) or what?

My app (FindAnyFile) provides a Finder-like interface in which it also offers a QuickLook preview command, which invokes [[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil]; Now, if it shows .abcdp files, it often, but not always, crashes. This has been happening for many macOS versions, at least since 10.15, up to 26.1. Also, it does not seem to matter which SDK/Xcode I build with, as I used several and all versions lead to the crash. The issue rather appears to be inside the QLplugin for the AB file (ABCardCollectionView etc.). I am able to trace this crash in Xcode. There are a LOT of errors and warnings coming up, and eventually the qlplugin throws an ObjC exception which in turn brings down my entire app (and here I thought that the XPC system was designed to expressly avoid such crashes). Possibly significant errors are: CNAccountCollectionUpdateWatcher 0x6000025cf800: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Error using remote object proxy when fetchAnonymousXPCEndpoint: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller" UserInfo={NSDebugDescription=connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller} connection to service named com.apple.coreduetd.people … CNPropertyNotFetchedException: A property was not requested when contact was fetched. I've attached the (mostly) complete console output from such a debug run. I have also an open bug report regarding this kind of crash (back then I was not able to reproduce it myself): FB15553847 Also, when I "Quick Look" the same file in Finder, I get a "Preview not permitted" for the same items that crash in my app. If I copy the same items to the Desktop, then Finder can QL them and my app doesn't crash when viewing the item on the Desktop. So, the crash only happens with the items inside ~/Library/Application Support/AddressBook/Sources/…/Metadata/. Now, here is the weirdest part: You might think: So, if the Finder shows "Preview not permitted", then my app trying to view those items is the result of that condition (even if that's not supposed to crash). However: I have a clean 26.1 install (in an Apple ARM VM) where Finder also says "Preview not permitted" for these items in the user's Library/AB/Metadata folder, but my app can QL those items without crashing! Also, I have one user who uses 26.1 and gets the crash with files in the same location. So, the "Preview not permitted" is probably not the cause of this crash, though it's suspicious that a user gets this at all - why can't a user QL the abcdp files in the Metadata folder but when copied to the Desktop, QL works? You'd think that Finder has the necessary entitlements to access the AB, or doesn't it? Of course, my app has permission enabled under Privacy & Security / Contacts (if it's disabled, then the app can't show anything but will also not crash). And it has the "Address Book" entitlement. Would be nice if this could be looked into and eventually be fixed. Alternatively, I'd welcome any suggestions on how to prevent my app from crashing if the qlplugin throws. But if you look at the stack trace you'll see that there's no method of my own app involved where I could insert an exception catcher. I added code to my previewItemURL delegate method to make sure the NSURL item is readable, and it is, even Of course, apart from the issue with .abcdp files, the QL operation in my app works flawlessly, i.e. I have never received any other crash reports relating to any other QL plugins. QuickLook for AddressBook crash messages

TL;DR I cannot install some Apple software because a certificate appears to have expired. How do I identify the culprit? I have been using Xcode 10.1 on 10.13.6 for a many years on my MacBook Pro, and suddenly it won't launch any more because it wants to install the "additional required components", but then fails at doing so with a weird "untrusted" error message. From the log file: Xcode[12324]: Package Authoring Error: PackageInfo bundle reference found without top-level bundle definition. Bundle will be skipped: <bundle id="*"></bundle> Xcode[12324]: Package: PKLeopardPackage <id=com.apple.pkg.MobileDeviceDevelopment, version=10.3.9000000000.1.1488876279, url=file:///Applications/Xcode10.1.app/Contents/Resources/Packages/MobileDeviceDevelopment.pkg> Failed to verify with error: Error Domain=PKInstallErrorDomain Code=102 "The package “MobileDeviceDevelopment.pkg” is untrusted." UserInfo={NSLocalizedDescription=The package “MobileDeviceDevelopment.pkg” is untrusted., NSURL=MobileDeviceDevelopment.pkg -- file:///Applications/Xcode10.1.app/Contents/Resources/Packages/, PKInstallPackageIdentifier=com.apple.pkg.MobileDeviceDevelopment, NSUnderlyingError=0x7f8240512710 {Error Domain=NSOSStatusErrorDomain Code=-2147409654 "CSSMERR_TP_CERT_EXPIRED" UserInfo={SecTrustResult=5, PKTrustLevel=PKTrustLevelExpiredCertificate, NSLocalizedFailureReason=CSSMERR_TP_CERT_EXPIRED}}} Everything else works fine on the system. All I changed recently, before this started happening, was to re-install 10.13.6 fresh, and then restore from a recent Time Machine backup, all in order to fix an iCloud issue that seemed to be related to SSL trust issues when contacting the iCloud sync server, but was fixed with this re-install. I've even re-downloaded the Xcode10.1.xip from Apple, but that makes no differences, it's not Xcode that's broken. The log suggests that a cert has expired, but which one would that be? I have looked at the Certificates in Keychain Access, but none of the ones that appear to be related to Apple are expired as far as I can tell. Maybe one is missing, but which? Any ideas how to analyse or fix this? (I need Xcode 10.1 because the macOS apps I make need to remain backward compatible with 10.11 and up, and I'm often debugging on High Sierra for that purpose. Besides, the same Xcode 10.1 works fine on two other Macs running 10.13.6.)

I like to find a way to identify network volumes, and whether they're run by certain servers, e.g. specifically whether they're on a Synology NAS. Reason is that Synology, while apparently supporting the Spotlight-over-SMB API, comes with a lot of bugs, requiring me to work around them when searching on those volumes with the macOS Spotlight API. I could, of course, ask the user to "configure" each mounted volume in my software, but I'd rather do this automagically, if possible, as it's less prone to user mistakes. So, my question is: Is there a way to learn a bit more about the server of a mounted network volume? E.g., if I could learn its IP address, I could try to connect to it via http protocol and then maybe get a useful response that identifies it as being from Synology. Or, alternatively, can I tell which SMB volumes are served by a Mac, so that I can at least assume that those handle Spotlight calls correctly, while I assume anything else is buggy (so far, AFAIK, Synology is the only other SMB server that supports Spotlight search). I've tried to find some data in the IORegistry, but that doesn't seem to store anything about network vols. The statfs function doesn't seem to give me anything for that either, nor do the various fcntl calls as far as I could tell. I also checked with the DA apis, e.g.: DASessionRef daSession = DASessionCreate (NULL); CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true); DADiskRef daDisk = DADiskCreateFromVolumePath (NULL, daSession, furl); if (daDisk) { CFDictionaryRef daInfo = DADiskCopyDescription (daDisk); NSLog(@"%@", daInfo); } However, this only prints basic information: DAVolumeKind = smbfs; DAVolumeMountable = 1; DAVolumeName = TheNAS; DAVolumeNetwork = 1; DAVolumePath = "file:///Volumes/TheNAS/"; Where, then, does Finder's "Get Info" get the smb path from, for example?

I have received a few crash reports for my app "Find Any File" with an assertion failure as follows: assertion failure: "displayTiming != ((void *)0)" -&gt; %lld Googling this turns up nothing, though. I wonder if someone has some insight into why this might happen, and how to prevent it. One reporting user suggests that it happens when my app shows a very long list of items in an NSTableView (&gt;10000 elements). I have 4 reports from 3 users, and the main thread is doing something related to the table view each time, though not the same (the few other threads are all idle): Crash 1, in macOS 14.0 (23A344: Thread 0:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x182c69400 objc_msgSend + 0 1 AppKit 0x186f15400 -[CALayer(NSViewVisibleRect) NS_viewVisibleRectDidChange] + 40 2 AppKit 0x186900e10 NSViewHierarchyInvalidateVisibleRect + 276 3 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 4 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 5 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 6 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 7 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 8 AppKit 0x1869990e0 -[NSView translateOriginToPoint:] + 164 9 AppKit 0x186984108 -[NSClipView _immediateScrollToPoint:] + 420 10 AppKit 0x186983eb8 -[NSClipView scrollToPoint:] + 184 11 AppKit 0x186998d80 -[NSScrollView scrollClipView:toPoint:] + 84 12 AppKit 0x1869448dc -[NSClipView _scrollTo:animateScroll:flashScrollerKnobs:] + 480 13 AppKit 0x186b65b24 __62-[NSScrollingBehaviorConcurrentVBL _stopGestureScrollTracking]_block_invoke + 192 14 AppKit 0x186e6a6e8 ___NSMainRunLoopPerformBlockInModes_block_invoke + 44 15 CoreFoundation 0x18310b8c0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 Crash 2, in macOS 14.1.1 (23B81): Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x18ba401f4 DYLD-STUB$$_Block_object_assign + 0 1 libsystem_blocks.dylib 0x18b506118 _call_copy_helpers_excp + 80 2 libsystem_blocks.dylib 0x18b505c68 _Block_copy + 376 3 libdispatch.dylib 0x18b641c7c _dispatch_Block_copy + 32 4 libdispatch.dylib 0x18b658df0 _dispatch_source_set_handler + 92 5 CoreFoundation 0x18b99e1e4 __CFRunLoopCopyMode + 540 6 CoreFoundation 0x18b8b7458 CFRunLoopAddObserver + 220 7 AppKit 0x18f0a687c _PerfAddRunLoopObserver + 192 8 AppKit 0x18f87cd60 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 368 9 AppKit 0x18f323318 -[_NSScrollingConcurrentEventMonitor startMonitoring] + 380 10 AppKit 0x18f321df8 -[NSScrollingBehaviorConcurrentVBL _scrollView:trackGestureScrollWithEvent:] + 884 11 AppKit 0x18f2e67f8 -[NSScrollingBehaviorConcurrentVBL scrollView:scrollWheelWithEvent:] + 512 12 AppKit 0x18f241770 forwardMethod + 252 13 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 14 AppKit 0x18f241770 forwardMethod + 252 15 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 16 AppKit 0x18f241770 forwardMethod + 252 17 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 18 AppKit 0x18f241770 forwardMethod + 252 19 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 20 AppKit 0x18fc45880 -[NSCollectionView scrollWheel:] + 180 21 AppKit 0x18f241770 forwardMethod + 252 22 AppKit 0x18f241770 forwardMethod + 252 23 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 24 AppKit 0x18f241770 forwardMethod + 252 25 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 26 AppKit 0x18f241770 forwardMethod + 252 27 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 28 AppKit 0x18f1d27b0 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 652 As you can see, there's no code of mine involved at the time of crash. The other (and older) reports are similar, in macOS 13.6.1 and macOS 13.1. All four happened on ARM architecture (which may not be significant due to small number of samples). Memory use of app was not critical (in one case it was about 9 GB total, in others below 4 GB). The "Binary Images" section only lists Apple libs, apart from my app's. So, there seems to be no 3rd party ext involved. I've attached a full report as well. Full report of Crash 1

On macOS, if I mount two volumes whose name is the same, the second one gets renamed, by appending "-1" to its name. I need a method to determine the original volume name, i.e. without such a suffix. (Of course, I cannot blindly remove any "-" plus digits because the volume may actually be named like this.) I can find the original name when using the mount command in Terminal: //tt@192.168.61.121/NAS2 on /Volumes/NAS2 (smbfs, nodev, nosuid, mounted by tt) //tt@QNAS%28AFP%29._afpovertcp._tcp.local/NAS2 on /Volumes/NAS2-1 (afpfs, nodev, nosuid, mounted by tt) Here, I can tell that "/Volumes/NAS2-1" was originally named "NAS2" on the network. How do I determine the share's name without invoking such tools, but via CF or other macOS functions, with providing the path or URL of the mounted volume (such as "/Volumes/NAS2-1")?

When using the mount command on macOS, I can see mounted network servers like this: //tt@mynas.local/NAS on /Volumes/NAS (smbfs, nodev, nosuid, mounted by thomas) In this example "thomas" is my macOS user name, under which I mounted the "NAS" volume. But there's also the "tt" name before the "@" - and that's what I'm interested in getting - that's the user name known to the server, i.e. the name I logged in on the server when the connection prompt appeared. How do I get this name (tt) via macOS APIs? I can get it via "mount", but that requires parsing and is inefficient, and so I like to avoid that if possible. man mount mentions getfsent(), but in my testing it only lists internal volumes, not network volumes.

I have two apps that are exempt from the need to be sandboxed. One has been in the MAS since the first day in 2010, and the other was added only a bit later, when there still was no sandboxing in place. When Apple added requirements for sandboxing, they exempted existing apps like mine under certain conditions. For years, this was no problem, but lately, nearly every other time I submit an update or a TestFlight beta, I get the app rejected for not being sandboxed, even though I explain the situation in the app's Review Notes. It's always a tedious fight convincing the reviewer to let the app pass. And, of course, it delays my releases each time. It's frustrating and exhausting. Sadly, I cannot find any public documents that confirm my claim of this exemption. So, it's always possible that the reviewer may read my note but still not believe me. Are there others here who still have such non-sandboxed in the MAS? How do you deal with this? Or do you know of documents or websites that I can refer the reviewer to?

Has anyone else seen this happen with their macOS apps in TestFlight? The situation: When I launch my app that's been downloading via TestFlight.app, it often comes up with its main window deactivated. Also, when I have open more than one window and close one, the other window doesn't come to front either. In either case, activating the app or clicking into a window will activate it properly. It feels as if there's another window that's not visible but somehow keeps getting activated. I have this happen on two Macs running both Sonoma and Monterey. Also, if I take the very same build that I had uploaded to TestFlight and run it directly, it works correctly. So I suspect that TestFlight somehow messes with my app's windows. If you want to test this yourself: Get the app thru this link: https://findanyfile.app/TestFlight/ Then launch it. Often, the Find window will already come up without being active. Activate it, then open the Preferences window by typing cmd-comma. Then close the Prefs window with cmd-W. This should re-activate the Find window but will instead leave it deactivated, and none of the menu shortcuts (such as cmd-comma, cmd-N or cmd-Q) work. That's the bug. I wonder how I can debug this to find a work-around for this odd behavior. E.g, I'd like to see if there is indeed a semi-hidden window causing this. How would I do this? I could probably make a new TestFlight build that queries the app's windows array and logs it. But are there other ways to query an app's windows? I tried AppleScript, but since my app isn't scriptable, I only get an error -1728 for tell app "Find Any File" to get windows.